Nebula 2/Nebula Two.iso/Documents/PressReleases93/07July/Shopper.txt

Text File | 1995-06-12 | 19KB | 343 lines

Item    4945697                 93/07/22        13:10
From:   [e-mail]@INET#          Internet Gateway
Subject: Taking the NEXTSTEP:Excerpt from Computer Shopper

Hello User Groups,

Here is a great review on NEXTSTEP from the Computer Shopper...

Conrad Geiger


____________________________________________________
COMPUTER SHOPPER

Tech Section Development Tools

Taking the NextStep, Part One By Bruce Graves July 1993 Page 551

The first time I ran into NeXT computers (and Steve Jobs, NeXT's CEO, almost
literally ran into me) was in 1989, my senior year at Cornell University.
Jobs had just given a presentation about NeXT computers and was walking out of
Carpenter Hall, one of Cornell's engineering buildings.  I was hobbling in the
door on crutches, having injured myself that morning playing basketball.  Jobs
was so engaged in a conversation that he didn't notice me at all, and only his
companion's quick reaction saved me from a second crash to the floor that day.

Four years later, a NeXT machine (on loan from NeXT) dominates my office.  Its
17-inch, flat-screen color display dwarfs my PC's 14-inch monitor, while its
sleek, two-and-a-half-inch-high CPU case makes my PC look like a mini-
computer.  But don't plan on purchasing your own NeXT system--NeXT is getting
out of the hardware business.  Do keep your eyes open for NeXTSTEP, NeXT's
evolutionary--and in some ways revolutionary--operating environment for 486 or
higher PC's, expected sometime this summer.

But what is NeXTSTEP?  How does it differ from an environment like Microsoft
Windows, especially from a developer's perspective?  And do all the
differences represent steps forward?  To find out, I experimented with the
system for a little over two months, them attended a week-long class called
"Programming NeXT Computers," affectionately nicknamed Dev-Camp.  The course
is sponsored by NeXT and is designed to introduce developers to NeXTSTEP and
the concepts of object-oriented programming in general.

It turns out that complete answers to my original questions, never mind all
the new ones that came up as I learned about NeXTSTEP, would fill hundreds of
pages.  Almost every aspect of NeXTSTEP, from its interface to its suite of
development tools, is unique. As a result, I've split this article into two
parts.  This month, we'll take a look at what it's like to use NeXTSTEP, how
its underlying design is different from environments like Microsoft Windows,
and why it's so easy to create basic NeXTSTEP applications.

Next month, we'll dig a little deeper and examine how NeXTSTEP displays and
prints graphics and text.  We'll also see how simple it is to take advantage
of "Distributed Objects," which allow programs to transparently access data
and code on any NeXTSTEP machine on a network.  Hopefully, a brief look at
topics like these will give you a feel for why some developers, once they've
played with NeXTSTEP, are completely hooked.  On the other hand, we'll also
look at a few issues that might explain why, despite all of its strength,
NeXTSTEP doesn't dominate the marketplace.

NEXTSTEP

NeXTSTEP is an operating environment that consists of a graphical user
interface (GUI, pronounced "gooey") that sits on top of Mach, an operating
system that is upwardly compatible with Unix 4.3BSD. In addition to standard
Unix features, such as pre-emptive multitasking, Mach also supports multiple
threads, memory-mapped files, message-based interprocess communication, and a
host of other facilities.  Windows NT, which supports most of these features,
too, was heavily influenced by Mach, and future version of IBM's OS/2 are
likely to be based on it.

Figure 1 displays part of a typical NeXTSTEP screen, also known as the
workspace.  The file Viewer, in the center of the image, allows you to
navigate the Unix directory structure, manipulate files and directories, and
launch applications.  The center of the File Viewer shows the current
directory hierarchy as a series of icons, and the files in each of these
directories are listed directly below them.  The top of the File Viewer is
called the shelf, where you can place frequently used files or directory
folders for quick access.  To place an item on the shelf, you drag its icon
from the row in the center and drop it on the shelf.

On the right side of the screen is the application dock, where you can place
frequently used applications icons.  Placing an application icon on the dock
is just like placing it on the File Viewer's shelf; you drag it from the File
Viewer and drop it on the dock.  Consistency like this one of NeXTSTEP's
strengths.  Once you figure out how to do something in one context, you can
usually figure out how to accomplish the same thing anywhere--without reaching
for a manual.

NeXTSTEP menus are vertical lists that can be displayed anywhere in the
workspace, as opposed to drop-down menus that appear at the top of each
program's main window.  Applications usually take advantage of hierarchical
menus, where clicking on one menu entry display a submenu to the right of the
original.  If you use the entries in a particular sub-menu frequently, you can
"tear it off" and place it anywhere on the screen.  Only the active
application's menus are visible; NeXTSTEP hides background applications' menus
to save screen space.

NeXTSTEP windows differ just enough from Microsoft Windows' windows to drive
you crazy if you have to  switch between them frequently. Apparently to avoid
legal issues, NeXT placed the minimize button in the upper left corner of a
window's title bar and put the close button in the upper right corner, exactly
the opposite of Windows conventions (there is no such thing as a maximize
button under NeXTSTEP).  Along the same lines, verticle scroll bars appear on
the left side of windows, and the up and down arrows are grouped together at
the bottom of the scroll bar.

Keyboard usage is different under NeXTSTEP, too.  NeXT doesn't rely on
numbered function keys at all, and they've added a special Command key
(simulated by a keystroke combination on PCs) that's dedicated specifically to
keyboard shortcuts.  For example, Command-s always means "Save," while Command-
q always means "Quit." Compare this to keyboard shortcuts under Microsoft
Windows, where Shift-F12 saves files in Microsoft Windows, for Windows,
invokes a settings dialog in Borland's Quattro Pro, and probably does
something completely different in tens of other applications.

Unlike Windows, which is designed to operate with or without a pointing
device, NeXTSTEP always assumes that a mouse is available and relies on it
heavily.  For example, there's no easy way to access menu entries that don't
have Command-based accelerators assigned to them without using the mouse.  You
can't jump from one application to the next from the keyboard; again, you must
reach for the mouse. And when NeXTSTEP's equivalent of an OK/Cancel dialog
appears, you can hit Enter to accept it, but only a mouse click will cancel
it. Hitting Escape only produces a beep.

These are only a few of the cosmetic differences between NeXT-STEP and other
GUIs.  Their significance varies, depending on what you're used to and how
often you have to switch back and forth between different environments.
Still, they illustrate a philosophy that pervades NeXTSTEP.  Its designers
favored elegance and simplicity and ignored existing conventions that they
didn't feel made sense.  This is important to users, but it's even more
important to developers.


AN OO GUI?

GUIs like Microsoft Windows started as a group of interface elements and a set
of API functions to manipulate them.  Since object-oriented programming (OOP)
has surged in popularity, various vendors, including Microsoft, have strapped
applications frameworks on top of existing GUIs.  These frameworks encapsulate
the details of the underlying GUIs and allow programmers to view them from an
object-oriented perspective.  However, the GUIs themselves were mostly written
in C, which doesn't support OOP directly.

NeXTSTEP is different.  It isn't a set of stand-alone interface elements, and
it doesn't have a traditional API. Instead, NeXTSTEP is a hierarchy of
Objective C classes.  In effect, it is a GUI and an application framework
rolled into one. Unlike other GUIs, which allow you to write applications in
any language that can call traditional C or Pascal functions, NeXTSTEP
requires that the parts of an application that interface with the GUI directly
be written in Objective C (though other parts of the application can be
written in other languages, such as C++).


A SAMPLE PROGRAM

To get a feel for some of the advantages of a truly object-oriented GUI, we'll
create a very simple NeXTSTEP program called Side, which will display a window
that contains a slider and a text field.  The position of the slider will
range from zero (at it's far left) to 100 (at its far right).  As you move the
slider back and forth, the text field will display a number corresponding to
its position.  If you enter a number in text field and hit Enter, the slider
will position itself appropriately.  But here's where it gets interesting:  We
won't write a single line of code.

The first step in creating Slide is to run an application called Project
Builder, or PB, and create a new project.  PB is similar in many respects to
Borland's integrated Development Environment and Microsoft's Programmer's
Workbench for Windows.  It keeps track of all of your program's components and
automatically creates a makefile that it uses to build your application.

Once you've created a new Slide project, you can double-click on one of the
files that PB creates for you automatically, SLIDE.NIB.  The NIB extension
stands for NeXT Interface Builder (IB), which is where most of the work on an
application's interface takes place.  Double-clicking on a NIB file launches
IB automatically. PB is still running in the background.

Interface Builder lets you to lay out interface elements, such as windows and
controls.  When you open a new project in IB, it automatically creates a main
window and a menu with a few basic entries, such as Quit, for your
application.  IB also displays a window that contains a palette of common
controls.  Adding a slider and a text display to the Slide program is as
simple as dragging copies of them from the palette and dropping them in the
main window--similar to Visual Basic.

After you place a control in the main window, you can hit Command-1 to bring
up an inspector window.  Inspector windows display information about the
object that is currently selected and allow you to modify some of its
attributes.  For the slider, the inspector displays its minimum value (which
defaults to 0), its maximum value (which defaults to 1), and its current
position (a number between 0 and 1).  You can change these values by entering
new numbers in the appropriate fields.  We'll change the maximum value from 1
to 100 and set its current position to 0.


ACTION!

To try out an interface, you simply hit Command-r, the keyboard shortcut for
Test interface.  The main window, which contains a slider and a text field,
appears, along with the program's menu. You can move the slider, but it
doesn't update the text field. Similarly, you can enter a number in the text
file, but it won't affect the slider.  Selecting Quit from the application's
menu returns you to IB.  Under most other GUIs, it would be time to save the
interface and write some code to connect the two objects; NeXTSTEP is
different.

In IB, holding down the Ctrl key and clicking on the slider causes a thin
black line to appear.  One end of the line is attached to the slider, and the
other end follows the mouse cursor. Moving the cursor over the text field and
releasing the mouse button causes the line to "connect" the slider to the text
field. (see Figure 2).  When this connection appears, the inspector window
(which we used to set the slider's range, above) changes.  It now lists two
columns of text, one called Outlets and the other called Actions.  For you to
understand what the entries in these columns refer to, it's necessary to
explain a little about Objective C.


OBJECTIVE C

Objective C is an extension to standard C that provides object-oriented
capabilities.  To do this, Objective C allows you to define classes and adds a
mechanism that allows you to send messages to class instances, also known as
objects.  Objective C also adds one new variable type, id, which is a pointer
that can point to any type of object.  These are really the only changes that
Objective C makes to the C language.

At first glance, Objective C appears to add fewer capabilities than C++ does.
This is true in some areas, since C++ was designed to be a "better C," while
Objective C was only intended to add object-oriented features.  However, in
parts of the object-oriented arena, Objective C extends C further than C++.
Specifically, Objective C provides a capability called "dynamic binding" that
C++ doesn't fully support.

In this context, dynamic binding means that the compiler doesn't have to know
everything about the objects that messages are being sent to.  For example, in
Objective C, the expression anObject aMessage; sends a message to an object.
Sending a message to an object is similar to calling a C++ object's member
function. Its analog in C++ would be anObject->aMemberFunction();.

The important difference between the two, however, is that a C++ compiler
needs to know something about anObject's type.  On the other hand, an
Objective C compiler doesn't care what type of object anObject is.  All the
decision making can be delayed until run time. This adds an incredible degree
of flexibility, as you'll see shortly.

WHAT DYNAMIC BINDING DOES FOR YOU

How does any of this relate to the Outlets and Actions columns in IB's
inspector window?  As you'll recall, the line that we drew comes from the
slider and goes to the text field.  These objects are actually instances of
two NeXTSTEP Objective C classes, called Slider and TextField, respectively.
Both descend from another NeXTSTEP class Control.

The Control class (and hence all its descendants) contains a member variable
called target which is of type id (recall that id is a pointer to any type of
Objective C object).  When you connect two objects in IB, the object that you
draw the line from displays all of its id fields in the Outlets column.  This
allows you to specify which one of its id fields (target in this case) should
point to the object that you connected the line to (the text field).  You
choose the proper id field by clicking on its entry in the Outlets column.

What about the Actions column, however?  The object that you connect the line
to (the text field) displays a list of its methods (analogous in many ways to
C++ member functions) in the Actions column.  In this case, this allows us to
specify which message should be sent from the slider to the text field
whenever the slider is moved.  The text field displays a list of seven
methods, and the one we're interested in is called takeDoubleValue.

All of this is much simpler to do than it is to explain. Once we've drawn the
line from the slider to the text field, we can click on the target entry in
the Outlets column and the takeDoubleValue entry in the Actions column.  It's
just as easy to connect the text field to the slider.  We simply draw a line
from the text field to the slider, once again clicking on the target entry in
the Outlets column and the takeDoubleValue entry in the Actions column.

After making these connections, you can hit Command-r again (to test the
interface) and see what happens.  Amazingly enough, moving the slider
automatically updates the contents of the text field, and entering a number in
the text field and hitting return moves the slider!  But how does this work
without any code?

What's really going on here is that whenever you move the slider, it examines
its target field.  When it discovers that it points to something (the text
field), it sends a message (takeDoubleValue) to that object and passes a
pointer to itself as a parameter. The text field's takeDoubleValue method uses
the pointer that it receives to ask the slider (the object that sent the
message) what its current position is, then displays that value in the text
field.

Interface Builder doesn't limit you to send messages between NeXTSTEP
interface elements.  You can use IB to connect any type of object to any other
type of object.  For example, you could connect a slider to an object of your
own that takes a number and multiplies it by two.  You could then connect this
object to a text field, where it could display its results.  You would have to
write a little bit of code to create an object of your own--about three lines'
worth.


BACK TO PROJECT BUILDER

Until now, we've done everything from within the Interface Builder. To produce
a stand-alone application, you save the work you've done in IB (which updates
the NIB file) and return to the Project Builder.

Hitting the Build button causes PB to execute the makefile that it has
constructed; the result is a stand-alone version of the Slide program.

But how does your application work without any handwritten code?  Instead of
requiring you to write the routines that create and display you inter-face
objects manually, NeXTSTEP handles the details for you.  The DevCamp
instructor drew an excellent analogy: He described the NIB file as a
collection of "freeze-dried objects."   When you execute you application,
NeXTSTEP loads the associated NIB file and, in effect, "adds water."  As a
result, all the objects that you laid out in IB come to life automatically.



UNTIL NEXT MONTH

There's a lot more to writing simple NeXTSTEP programs, never mind full-
fledged applications, than we've covered here.  For example, nothing that
we've seen so far has shown us how to write a program that doesn't rely on
built-in interface objects like sliders and text fields.  What if you want to
draw a line, or write a NeXTSTEP version of the famous "hello, world" program?

Next month, we'll see how to display graphics and text in a window, and why
every application automatically inherits the ability to print or FAX any of
its images--once again, without writing any code.  And we'll look at a few
additional topics that will make you ask, "Why hasn't Microsoft done this
under Windows?"



Figure 1:  A typical Nextstep screen, also known as the workspace. The file
viewer, in the center of the image, allows you to navigate the Unix directory
structure.

Figure 2:  The Interface Builder in action.  Moving the cursor over the text
field and releasing the mouse button causes the line to "connect" the slider
to the text field.

=END=